Add Book to My BookshelfPurchase This Book Online

Chapter 4 - Routing Protocols Used in TCP/IP

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Redistributing Route Information between Protocols
If you have the opportunity to build a network from scratch, and could design it such that the only devices to run routing protocols are routers, you could choose your favorite routing protocol and use that exclusively. Typically, however, the situation is that there is an existing network with an existing routing protocol in place and, more often than not, Unix machines have some routing responsibilities in a network. Because most Unix machines only support RIP, and it is unlikely that RIP will be the best choice of routing protocol for an internetwork of any size, the question arises of how more than one routing protocol can coexist on an internetwork, either permanently or during a period of migration.
The answer is redistribution. A router can be configured to run more than one routing protocol and redistribute route information between the two protocols. The idea is that the internetwork will have multiple domains, each operating with a different routing protocol. At the border between these domains, one router has the responsibility of running both routing protocols and informing each domain about the other's networks in the appropriate routing protocol. This is illustrated in Fig. 4-23.
Figure 4-23: An internetwork where the use of redistribution is appropriate
In this figure, the router has to run both RIP and IGRP, then inform domain A about the networks in domain B with RIP updates and inform domain B about domain A's networks using IGRP updates. The router in this figure will only be able to assign one metric to all the routes that it redistributes from one domain to another; it cannot translate metrics between protocols. At first, this may seem to be a drawback, that all networks are redistributed with the same metric value, no matter where they are located in the other domain. In reality this is not a problem, because to get from domain A to domain B, all connections have to go through the same router; the initial part of the journey is identical when sending packets between domains.
In Fig. 4-23, a packet destined for domain A, originating in domain B, reaches router 1. Router 1 then has a routing table filled with entries for the networks in domain A that have been calculated using RIP updates. The packet will follow the best path to its destination network.
The following is an example of how, in Fig. 4-23, the routing protocol processes could be configured on router 1 to redistribute routes between the RIP and IGRP domains.
If we take a basic configuration for both RIP and IGRP, we add the redistribute commands shown in bold type:
router igrp 12
timers basic 15 45 0 60
network 164.8.0.0
network 193.1.1.0
no metric holddown
metric maximum-hop 50
redistribute rip
default - metric 300 344 200 200 200
router rip
network 150.1.0.0
network 120.0.0.0
redistribute igrp 12
default-metric 3
This assumes that domain A has network numbers 150.1.0.0 and 120.0.0.0 in it, and domain B has networks 164.8.0.0 and 193.1.1.0 in it.
The five values following the default-metric entry in the router IGRP section are the metrics that will be sent out in IGRP updates, for routes learned about via RIP. In the router RIP section, routes learned from IGRP updates will be advertised with a metric of 3. It must be noted that the numbers shown here are random. In most instances this does not matter, because all cross-domain traffic has to go through router 1 as previously explained.
We will now look at a few more examples of redistributing route information between protocols of different types.
Redistributing between RIP and OSPF
Let's take the example of one RIP domain and one OSPF domain needing to exchange information (Fig. 4-24). This is very much like the last example we used to redistribute route information between RIP and IGRP.
Figure 4-24: Internetwork redistributing between the OSPF and RIP protocols
As before, we have connected the Ethernet 0 ports of router 1 and router 3 to the same hub, so that the Ethernet 0 port of router 3 can be brought in to an up state and participate in the routing processes, even though these two Ethernet ports are on different network numbers. This is not good practice in general and should be used only in a lab environment.
The configurations and routing table for each router in this instance are shown in Fig. 4-25.
router1 #wri t
Building configuration...
Current configuration:
!
version 10.3
hostname router1
!
enable secret 5 $1$W6qH$DTNrEHmJrn6QqYcMu5PRh.
enable password test
!
!
interface Ethernet0
ip address 120.1.1.1 255.0.0.0
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
router rip
network 120.0.0.0
!
!
line con 0
line 1 16
transport input all
line aux 0
transport input all
line vty 0 4
password ilx
login
!
end
router1#sho ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP extemal, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate defauft
Gateway of last resort is not set
C 120.0.0.0 is directly connected, Ethernet0
R 150.1.0.0 [120/4] via 120.1.1.2, 00:00:1 1, Ethernet0
Router 2
router2#wri t
Building configuration...
Current configuration:
version 10.3
!
hostname router2
!
enable secret 5 $1$/P2r$ob00lmzYqpogV0U1g1O8U/
enable password test
!
interface Ethernet0
ip address 120.1.1.2 255.0.0.0
!
interface Serial0
ip address 150.1.1.1 255.255.0.0
!
interface Serial1
no ip address
shutdown
!
router ospf 10
redistribute rip
network 150.1.0.0 0.0.255.255 area 1
defauft-metric 64000
!
router rip
redistribute ospf 10
network 120.0.0.0
default-metric 4
!
!
line con 0
line 1 16
line aux 0
line vty 0 4
password ilx
login
!
end
router2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
C 120.0.0.0 is directly connected, Ethernet0
C 150.1.0.0 is directly connected, Serial0
Router 3
router3#wri t
Building configuration...
Current configuration:
!
version 10.3
hostname router3
!
enable secret 5 $1$cNaQ$a4jcvrXlzVO4cwJB7RP5j1
enable password test
!
!
interface Ethernet0
ip address 193.1.1.1 255.255.255.0
!
interface Serial0
ip address 150.1.1.2 255.255.0.0
clockrate 64000
!
interface Serial1
no ip address
shutdown
!
router ospf 10
network 150.1.0.0 0.0.255.255 area 1
!
!
line con 0
exec-timeout 0 0
line 1 16
transport input all
line aux 0
transport input all
line vty 0 4
password ilx
login
!
end
router3#sho ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate defauft
Gateway of last resort is not set
O E2 120.0.0.0 [110/64000] via 150.1.1.1, 02:03:51, Serial0
C 150.1.0.O is directly connected, Serial0
C 193. 1. 1.0 is directly connected, Ethernet0
Figure 4-25: Router configurations and routing tables for OSPF and RIP redistribution
The routing tables of router 3 and 1 show that the redistribution process functioned as expected. Router 3 knows about 120.0.0.0 via the OSPF process on router 2, and uses the OSPF default metric set in router 2 for that destination. Router 3 considers 120.0.0.0 as an external network, as the RIP domain is considered a different autonomous system. Router 1 knows about network 150.1.0.0 from the RIP process on router 2, and uses the RIP default metric set on router 2 for this entry.
In this small internetwork, RIP does not need to send advertisements out the Serial 0 port of router 2, so it can be disabled on this port by adding the following entry in router 2.
Router2(config)#router rip
Router2(config-router)#passive-interface serial 0
If this setup were part of a larger internetwork, there would be the possibility of a route existing from router 3 to router 1, via some other router that also is performing redistribution. This could cause a routing loop under certain conditions. To prevent this possible loop condition, it is a good idea to tell the RIP process on all routers performing redistribution to prevent routes that originated in the RIP domain from being readvertised back in to the RIP domain from the OSPF domain. To achieve this, we use access lists. An access list is a useful feature that allows almost infinite customization of the operation of your network.
An access list contains a series of commands that either permit or deny specific types of packets from getting through a given interface. These access lists are applied to either inbound or outbound packets.
The objective of the access list here is to tell all routers redistributing from OSPF into RIP not to send information regarding the 150.1.0.0 network from the OSPF domain back to the RIP domain. The entries in the configuration of router 2 to achieve this are as follows:
router rip
distribute-list 9 out ospf 12
!
access-list 9 deny 150.1.0.0 0.0.255.255
access-list 9 permit 0.0.0.0 255.255.255.255
The first line in the router RIP section specifies the access list number, 9, to be applied to packets coming out of the OSPF autonomous system 12. The access list itself contains two entries, the first of which is to deny any packets from the 150.1.0.0 network. The 0.0.255.255 is a mask value. The second entry permits all other packets. This is necessary because the last, and unseen, line in any access list denies all packets.
Another, potentially more useful example is to examine how OSPF could be added to the backbone of a simple internetwork that uses RIP for nonbackbone locations. This can be done if we reconfigure our lab a little, by using two more DTE/DCE cables. The configuration that we will build in our routers is shown in Fig. 4-26.
Figure 4-26: OSPF as a backbone protocol for a RIP internetwork
In this configuration, RIP does not communicate between routers over the OSPF area 0 backbone, so we will use the passive-interface command to stop those RIP advertisements coming out of the serial interfaces of all routers with the following configuration entries.
Router rip
passive-interface serial 0
passive-interface serial 1
RIP routes can then be redistributed in to the OSPF area 0 with the following commands:
router ospf 9
redistribute rip subnets
This differs from previous redistribution commands because we are explicitly telling OSPF to redistribute subnet information. Without this command, OSPF will redistribute only those networks without netmask information.
All RIP domains receive route information from other RIP domains and the OSPF backbone via the following configuration entries:
router rip
redistribute ospf 9
default-metric 10
The final configurations and routing tables for this example are given in Fig. 4-27.
router 1
routerl #wri t
Building configuration...
Current configuration:
!
version 10.3
hostname router1
!
enable secret 5 $1$W6qH$DTNrEHmJrn6QqYcMu5PRh.
enable password test
!
!
interface Ethernet0
ip address 160.4.10.1 255.255.255.0
!
interface Serial0
ip address 160.4.6.2 255.255.255.0
!
interface Serial1
ip address 160.4.7.2 255.255.255.0
!
router ospf 9
redistribute rip subnets
network 160.4.6.0 0.0.0.255 area 0
network 160.4.7.0 0.0.0.255 area 0
!
router rip
redistribute ospf 9
passive-interface Serial0
passive-interface Serial1
network 160.4.0.0
default-metric 3
!
!
line con 0
line 1 16
transport input all
line aux 0
transport input all
line vty 0 4
password ilx
login
!
end
router1#sho ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
160.4.0.0 255.255.255.0 is subnetted, 6 subnets
160.4.40.0 [110/20] via 160.4.6.1, 00:05:59, Serial0
 
  O 160.4.5.0 [110/128] via 160.4.7.1, 00:05:59, Serial1
[1 10/1 28] via 160.4.6.1, 00:05:59, Serial0
160.4.6.0 is directly connected, Serial0
160.4.7.0 is directly connected, Serial1
160.4.10.0 is directly connected, Ethernet0
160.4.30.0 [110/20] via 160.4.7.1, 00:05:59, Serial1
router 2
router2#wri t
Building configuration...
Current configuration:
!
version 10.3
!
hostname router2
!
enable secret 5 $1$/P2r$ob00lmzYqpogVOU1g1O8U/
enable password test
!
interface Ethernet0
ip address 160.4.40.1 255.255.255.0
!
interface Serial0
ip address 160.4.6.1 255.255.255.0
clockrate 64000
!
interface Serial1
ip address 160.4.5.2 255.255.255.0
clockrate 64000
!
router ospf 9
redistribute rip subnets
network 160.4.5.0 0.0.0.255 area 0
network 160.4.6.0 0.0.0.255 area 0
!
router rip
redistribute ospf 9
passive-interface Serial0
passive-interface Serial1
network 160.4.0.0
defauft-metric 6
!
!
line con 0
line 1 16
line aux 0
line vty 0 4
password ilx
login
!
end
router2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP   
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
160.4.0.0 255.255.255.0 is subnetted, 6 subnets
160.4.40.0 is directly connected, Ethernet0
160.4.5.0 is directly connected, Serial1
160.4.6.0 is directly connected, Serial0
160.4.7.0 [110/128] via 160.4.6.2, 00:06:58, Serial0
[110/1 28] via 160.4.5.1, 00:06:58, Serial1
160.4.10.0 [110/20] via 160.4.6.2, 00:06:58, Serial0
160.4.30.0 [110/20] via 160.4.5.1, 00:06:58, Serial1
router 3
router3#wri t
Building configuration...
Current configuration:
!
version 10.3
!
hostname router3
!
enable secret 5 $1$cNaQ$a4jcvrXlzVO4cwJB7RP5j1
enable password test
!
interface Ethernet0
ip address 160.4.30.1 255.255.255.0
!
interface Serial0
ip address 160.4.7.1 255.255.255.0
clockrate 64000
!
interface Serial1
ip address 160.4.5.1 255.255.255.0
!
roader ospf 9
redistribute rip subnets
network 160.4.7.0 0.0.0.255 area 0
network 160.4.5.0 0.0.0.255 area 0
!
router rip
redistribute ospf 9
passive-interface Serial0
passive-interface Serial1
network 160.4.0.0
defauft-metric 4
!
line con 0
exec-timeout 0 0
line 1 16
transport input all
line aux 0
transport input all
line vty 0 4
password ilx
login
!
end
router3#sho ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, 0 - OSPF, IA - OSPF irder area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
Gateway of last resort is not set
160.4.0.0 255.255.255.0 is subnetted, 6 subnets
160.4.40.0 [110/20] via 160.4.5.2, 00:07:45, Serial1
160.4.5.0 is directly connected, Serial1
160.4.6.0 [110/128] via 160.4.7.2, 00:07:46, Serial0
[1 10/1 28] via 160.4.5.2, 00:07:46, Serial1
160.4.7.0 is directly connected, Serial0
160.4.10.0 [110/20] via 160.4.7.2, 00:07:46, Serial0
160.4.30.0 is directly connected, Ethernet0
Figure 4-27: Router configurations and routing tables for redistribution between an OSPF backbone and RIP domains
This gives us the results we expect, with each router knowing about all six subnets on the internetwork. As you can see from these routing tables, OSPF will share traffic between paths of equal metric. This is illustrated by looking at the routing table for router 3. In this routing table, 160.4.6.0 has two equal-cost paths, one via router 1, and one via router 2.
Routing between Autonomous Systems
Let's now look at a different situation, one in which we have different autonomous systems, both running EIGRP, that need to exchange route information. In this example, it is assumed that both autonomous systems are under common administration and the use of an exterior gateway protocol is not necessary.
By default, EIGRP will only send route advertisements to the one autonomous system; if two EIGRP processes for two autonomous systems are running on the same router, however, redistribution can be used to transfer information between each AS routing database.
Let's say we have a router with one interface in autonomous system 15, network 120.0.0.0, and one in autonomous system 16, network 150.1.0.0. Our objective is to transfer information regarding 120.0.0.0 into AS 16. The route protocol sections for this router are shown as follows:
router eigrp 15
network 120.0.0.0
redistribute eigrp 16
distribute-list 5 out eigrp 16
router eigrp 16
network 150.1.0.0
!
access-list 5 permit 120.0.0.0
The third line of this configuration enables the router to redistribute information from AS 16 into AS 15. The fourth line, in conjunction with the final line, restricts the information that is redistributed from AS 16 to only those routes in the 120.0.0.0 network.
IP Version 6
With all the good things we have discussed that are available for the current version of IP (version 4), why is there a need to discuss upgrading to IP version 6, sometimes referred to as IP Next Generation? For most private networks, the benefits of upgrading are not yet clear. The most commonly quoted benefit of Ipv6 is its increased address space. IPv6 uses a 128-bit address field, as opposed to the 32-bit space of IPv4. However, IPv4 has plenty of address size available for even the largest of private networks. IPv6 is most likely to deliver benefits to the private network by improved security at the network layer, routing table size reduction (reducing memory and processing requirements of routers) and improved auto-addressing of mobile users.
IPv6 is a different story for the Internet. There are plans to radically increase the number of Internet addressable devices, to make even household and consumer goods Internet addressable. That does require lots more address space. With that in mind, let's briefly look at how the current form of IPv6 came into being.
Background.     Having decided that the Internet needed the capability for drastically larger address space, the Internet Architecture Board considered three main proposals. The first became known as TUBA, which stands for TCP and UDP over Bigger Addresses. This proposal was based around the idea of switching from IP to CLNP (the Connection-less Network Protocol) as the network layer protocol for the Internet. CLNP is an OSI protocol that has a 20-octet address and at the time had an existing installed base and defined routing protocols. This proposal was not adopted as CLNP; even at the time it was an old and inefficient protocol that was not as widely accepted in the marketplace as Ipv4.
The second proposal became known as IPv7, then TP/IX and eventually CATNIP. This proposal was centered around the idea of defining a common packet format that would be compatible with IP, CLNP, and IPX. This proposal did not however reach maturity fast enough for the IAB.
The third and ultimately successful proposal started life as IP in IP. The basis of this proposal was to define two layers for the Internet, one for the backbone, and one for local deployment. This idea was refined in a proposal called IP Address Encapsulation, which became the preferred transition mechanism for Simple IP. Simple IP was basically an increase in address space from 32 to 64 bits and a cleanup of obsolete Ipv4 features to reduce the IP header size. SIP merged with a proposal called PIP, that improved upon Ipv4's routing efficiency to create a proposal called SIP Plus, known as SIPP. By modifying the address space, the IAB accepted this proposal as the way forward and called the protocol Ipv6. IPv5 was not chosen as it had already been allocated to a real time streaming protocol.
Technical Overview.     Increasing the size of the address fields is the easier part. Coping with IP reachability (by this I mean the ability of routers to navigate a packet through the network from source to destination), in a massively larger Internet is a significantly greater challenge. The only known technique that is adequate to contain the routing overhead for a system as large as the current Internet is the technique of hierarchical routing. In the absence of any other alternatives, the Internet routing system (both for IPv4 and IPv6 address space) still needs to rely on the technique of hierarchical routing.
While hierarchical routing certainly provides good scaling capabilities, it imposes restrictions for it to be effective. Among the most important restrictions is the requirement that the address assignment should reflect the underlying network topology. The practical implication of this is that once assigned, IP addresses need to be restricted to the geographic area of their origin, similar in concept to how the telephone network assigns an area code to a given geographic area. This concept is illustrated in Fig. 4-28.
Figure 4-28: Hierarchical addressing. With hierarchical addresses, ISPs in given geographic locations will have a set prefix. Changing ISPs or the physical connections into the Internet will mean renumbering to maintain effective address hierarchy.
Consequently, if a network changes its point of connection to the Internet, it may have to change its addressing as well.
This immediately causes an issue if a company changes its ISP, as it may require a renumbering exercise to maintain an effective Internet address hierarchy. Therefore, an essential precondition for hierarchical routing is the availability of practical renumbering technologies.
In IPv6, renumbering is handled by more sophisticated autoconfiguration capabilities than IPv4, enabling an IPv6 host to renumber without significant human intervention. Although autoconfiguration can simplify the configuration of new hosts, its main benefit is its ability to maintain effective Internet routing hierarchy.
To simplify host renumbering, IPv6 requires IPv6 hosts to be able to support multiple IPv6 addresses per interface. This is similar in concept to the Cisco interface command "secondary IP address," which allows an interface to use two IP addresses. The IPv6 mechanism of multiple addresses per interface goes further however. IPv6 allows the ability to identify an IPv6 address assigned to an interface as either "valid," "deprecated," or "invalid." A host can use a valid address both for the existing communications and for establishing new communications. In contrast, the host could use a deprecated address only for the existing communications, but is not allowed to use such an address for new communications. Finally, if a host has an address that is invalid, that address cannot be used for any of the new or existing communications. In the process of renumbering, a host's current IPv6 address would become deprecated, and the host would acquire (through one of the IPv6 address autoconfiguration mechanisms) a new (valid) address. As a result, all the new communications would use the new address.
IPv6 address autoconfiguration is supported via both stateful and stateless mechanisms. The stateful autoconfiguration is based on DHCP, appropriately modified for IPv6. The stateless address autoconfiguration eliminates the need to maintain DHCP servers. With stateless autoconfiguration, a host is expected to construct its IPv6 address by concatenating its MAC address with the subnet prefix that the host learns by using neighbor discovery from the routers that are on the same subnetwork as the host.
Getting a new address to a device is only part of the story. There are still a whole host of issues that are not covered by existing renumbering methods, including:
  Updating Domain Name System (DNS) databases for all the nodes whose addresses have been changed. It would also involve updating the information about the addresses of the DNS servers within the site.
  Renumbering involves changing routers' configuration information (for example, access control list filters and reachability information).
  Some TCP/IP applications rely on the configuration information (configuration databases) expressed in terms of IP addresses.
  If clients licensing databases are configured for a specific IP address, renumbering a site would involve changing the configuration information maintained by the clients.
None of these issues are covered by available renumbering methods. Maintaining effective hierarchy by renumbering still presents significant implementation problems.
How IPv6 Headers Work.      IPv6 has kept most of the characteristics of the original IPv4 protocol; the Internet could not have been so successful if the design of IPv4 had significant flaws. Thus, the IPv6 header bears more than a passing resemblance to the Ipv4 header. IPv6 headers are composed of an initial 64 bits followed by two 128-bit fields for source and destination addresses. The initial 64 bits consist of the following fields:
  Version
  Class
  Flow label
  Length of payload
  Type
  Hop limit
This is a simplification of the Ipv4 header, as it assigns a fixed format to all headers, removes the header checksum and the hop by hop segmentation procedure. The most significant of these changes is the removal of the hop by hop segmentation procedure. Previously, if a host had to send data across several media types from source to destination, the possibility existed that a packet would be sent that was too large for some media types to handle. For example, sending a packet from token ring network that has a maximum packet size of 4K to ethernet with a maximum packet size of just over 1.5K. In this case, the router connecting the two media types would segment the original packet. This does not happen in an Ipv6 network, which uses a procedure called path MTU discovery, ensuring that no segmentation is necessary.
On top of this fairly simple header, IPv6 supports the concept of header extensions. When header extensions are used, the final bits of each header define the function of the next header to follow, except in the case of the final header, which defines that the payload is to follow. This principle is illustrated in Fig. 4-29.
The available extension headers include the following:
  Routing header
  Fragment header
  Authentication header
  Encrypted security payload
  Destinations option header
Figure 4-29: Header extensions.
Ipv6 Address Routing.     With IPv4, we had the familiar setup of the first octet defining a class A, B, C or D address, which told us (along with any subnet mask applied), how to identify the network, subnetwork, and node numbers. Ipv6 is somewhat different in this respect, and we shall examine those differences here.
In IPv6 there are three categories of address, unicast, multicast, and anycast; there is no broadcast. Unicast is the same as point to point communication, a packet is sent to a specific address and no other. This address corresponds to a specific interface on a device. Multicast refers to the process of one packet being sent to a number of recipients. This is different to broadcast. With broadcasts, the packet sent is delivered to all devices on the subnet the broadcast is destined for. With multicast, the option exists for only a subset of devices on the destination subnet to receive the packet. The anycast option is similar to multicast; the difference is that the packet is only delivered to the first device in the anycast group that can receive the packet; it is not sent to all devices in the anycast group.
The convention for writing down these 128-bit addresses is to use blocks of four hexadecimal numbers separated by colons. An example is given below:
This is somewhat cumbersome. Not so much for users, that should be using names to address hosts in any case, but for administrators that still need to type numbers in to configuration files and databases. To abbreviate the notation, it will be convention to drop leading zeroes. This will be useful, particularly in the early days of IPv6, when most of the address space will be filled with zeroes. This convention is expanded to cover what is known as the double colon notation, which says if a double colon appears in an address, fill the address out to 128 bits by inserting the necessary number of zeroes between the double colons. Here's an example:
0000:0000:0000:0000:1111:2222:3333:4444
Could be represented by:
::1111:2222:3333:4444
Ipv6 address notation also has a facility to define a prefix in the same way that IPv4 did. In IPv4, the number of bits assigned to the address prefix, which determines the subnet address, could be identified by using the "slash" notation. An example that assigns the first twenty-four bits of a class B (which is equivalent to a netmask of 255.255.255.0) address to the subnet is given below:
173.8.4.3/24
The same can be done with Ipv6, the following example will identify the first 64 bits as the prefix to be used in routing tables that identify individual network segments.
FEDC::1234:2345:2222/64
Unicast Addresses.     The format of a global unicast address for an Ipv6 node is shown in Fig. 4-30. The first three bits, with value 010 identify the address as an aggregatable global unicast address. The subsequent fields are all now fixed length fields that replace the Registry and the variable length provider Ids of earlier incarnations of IPv6. With 13 bits allocated to the Top Level Aggregator, there are a possible 8,192 TLA assignments. This is expected to be enough to cover the necessary points of access to the core of the future Internet. Each one of these TLA assignments equates in physical terms to a backbone provider, or an exchange point.
Figure 4-30: Format of an IPv6 unicast address.
The Next Level Aggregator (NLA) equates to a specific ISP, and the Site Local Aggregator (SLA) equates to a segment at a given site, or end user location. With re-numbering in this scheme, the TLA and NLA may change, but the SLA and Interface ID will remain constant.
In fact, the interface ID will be a globally unique number, using the IEEE EUI-64 form, which is based on the more familiar 48 bit IEEE 802 MAC address specification. Given a 48 bit MAC address, you can generate a 64 bit EUI-64 address by inserting hexadecimal FF and FE between the third and fourth octet of the original MAC address.
There are some special addresses in Ipv6, just as there were special addresses in Ipv4, like the 127.0.0.1 loopback address. In Ipv6 the special addresses of interest include unspecified, loopback, site local and link local addresses.
The unspecified address consists of all zeroes, it may be used by a station as a source address, before it has received an IP address.
The loopback address in Ipv6 is simply 1, which can be noted as ::1.
Organizations that wish to run their internal network on Ipv6 technology can do so with site local addresses. Site local addressing has its own prefix, 1111 1110 11. The complete site local address will consist of this prefix, a set of zeroes, the subnet ID and the interface ID.
Devices that have not been configured with a provider based address or site local address may use link local addresses, which consist of the link local prefix (111 1110 10), a set of zeroes and an interface ID.
Multicast and Anycast Addresses.     Ipv4 has supported multicast since 1988, when class D addresses and IGMP (Internet Group Multicast Protocol) were proposed for this purpose. Ipv6 has been designed with multicast facilities built in to Ipv6 ICMP.
The IPv6 multicast format is shown in Fig. 4-31 and consists of eight ones, followed by a four bit flag, four bit scope and 112 bit Group ID. All the flag field does is identify an address as transient, if it is not an address that will be permanently assigned (like those in use on experimental networks such as the MBONE). The scope field is used to limit the propagation of multicast packets, like keeping a videoconference local, rather than having it find its way on to the global Internet.
Figure 4-31: Format of an IPv6 multicast address.
Examples of multicast addresses are FF02::1 that addresses all nodes, and FF02::5 that identifies all OSPF routers.
Anycast is still very new. The idea is that there will be well known addresses, similar in construction to multicast addresses, the difference is that the anycast packet is delivered to the nearest device that is a member of the anycast group. This functionality can be used to identify things like the nearest time or name server on the network.
Inter and Intra Domain Routing.     Intra domain routing is the more familiar routing for managers of private networks. We have looked at Intra domain routing within an Autonomous System by the use of IPv4 versions of RIP, OSPF, IGRP and others. IETF working groups are updating RIP and OSPF to accommodate Ipv6 and we can expect IPv6 versions of Cisco protocols like EIGRP also.
The updates to OSPF are minimal, essentially wherever a 32 bit address appeared in routing databases, a 128 bit address now appears for the IPv6 version. IPv6 RIP still uses distance vector mechanisms of update, like UDP broadcast updates every thirty seconds of route tables, to neighbors. The updates to RIP have been minimal. Most of the shortfalls of the original protocol have remained, and it is not expected that RIP will be widely deployed in Ipv6 environments.
Inter domain routing in Ipv6 is a different story. One of the greatest challenges to the Internet as it currently stands is the size of the routing tables at the core and the overhead necessary in table maintenance. In 1995, the Internet was in grave danger of falling over and not recovering. Only a quick fix supplied by Cisco kept it running. This fix reduced the amount of route updates sent on the Internet, reducing the amount of table calculation the Internet's central routers had to perform and the bandwidth used on core Internet links for these updates.
To reduce the size necessary for core Internet router routing tables, entries in these tables must be aggregated. Currently this takes the form of things like assigning any 194.x.x.x class C network to Europe, thus allowing Internet routers in the rest of the world to have one aggregated entry in their routing tables for all these class C networks, instead of individual entries for each one all pointing in the same direction.
The plan for Ipv6 inter domain routing is to apply hierarchy to provider addresses, to minimize the number of entries in core Internet routers. This presupposes the addressing scheme deployed in Ipv6 reflects the network topology.
Additionally, inter domain route updates will be exchanged via the Inter Domain Routing Protocol (IDRP), which is a significant departure from the current practice, that uses BGP4. The reason that BGP4 is not used in the Ipv6 world is that BGP4 was too heavily optimized for use in a 32 bit address world and could not be easily modified for 128 bit addresses. The main differences between BGP and IDRP are listed below:
  BGP uses TCP as the transport for update messages, whereas IDRP uses a datagram service.
  BGP used 16 bit autonomous system numbers to identify a domain, whereas IDRP uses variable length address prefixes.
  IDRP aggregates autonomous system paths by the use of routing confederations.
Neighbor Discovery.     Neighbor Discovery describes the interaction between nodes on the same network segment in an Ipv6 network. For example, to send a packet to a remote network, the device originating the packet needs to find a media address for the next hop router to send the packet to. In Ipv4, this was provided by the Address Resolution Protocol that maintained a list of media addresses (like MAC) to IP address information.
In IPv6, there are noticeable improvements in this area. All the mechanisms related to the interaction among hosts and routers on a single network segment are consolidated into a single protocol, the Neighbor Discovery Protocol (ND). ND replaces the IPv4 by the Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP) Router Discovery, and ICMP redirect, as well as providing some enhancements.
In contrast to IPv4, where the IP-to-link-layer address resolution is based on using ARP broadcasts, the IP-to-link-layer address resolution in IPv6 uses multicast. This allows a significant reduction in the number of address resolution-related interrupts on nodes other than the target of the resolution.
IPv6 replaces the ICMP redirect message with the ND redirect message. To support multiple IP subnetworks on the same physical network segment, IPv6 relaxes the constraint on accepting redirects, allowing a host to accept redirects regardless of whether or not the next hop (specified by the redirect) is on the same IP subnetwork as the host itself. Moreover, in contrast to IPv4, in which the target address in an ICMP redirect (to which traffic for a destination should be sent) could only identify a router, the target address carried by an ND redirect message could either identify a router or the ultimate destination (host). To avoid an extra step needed to resolve IP-to-link-layer address mapping, the ND redirect message includes both the IPv6 and the link-layer addresses of the target.
One of the common problems associated with the host to its first-hop router interaction is the problem of detecting router failures ("dead" router detection). To minimize disruptions in the presence of router failures, ND introduces an explicit mechanism that allows one node (either a host or a router) to verify if a node (either a host or a router) on the same network segment is up.
In contrast with IPv4, the addressing information acquired through ND carries explicit timeouts. Explicit timeouts set by the senders of information allow the senders to directly control the lifetime of the information. This feature is expected to be especially important in the situations where the information could be fairly dynamic (for example, in the presence of mobile hosts).
ND provides hosts with such information as the maximum hop count that hosts should use in outgoing packets and some datalink layer specific parameters, such as the maximum transmission unit (MTU). While ND improves the interaction among nodes (hosts, routers) on the same network segment, not all of these improvements would always be available via this protocol. Most of the functionality provided by ND assumes the link layer media supports multicast capabilities in a simple fashion (similar to what is available on Ethernet). In an environment where the link-layer multicast is either nonexistent, such as in Asynchronous Transfer Mode (ATM) or relatively expensive, relying on multicast servers to support full ND, functionality may be suboptimal.
The Transition from IPv4 to IPv6 Providing a manageable transition from IPv4 to IPv6 is crucial for the success of IPv6. During the transition period, it would be essential to maintain compatibility with the existing installed base of IPv4 hosts and routers. Because it is very difficult to predict how long the transition would take, it would be safe to assume that such compatibility would be needed for a very long time. In fact many predict that a transition to a further enhanced IP protocol will be underway while the Internet is still transitioning to Ipv6.
In a somewhat simplistic model, the transition process could be viewed as consisting of two components, transition to IPv6 hosts and transition to IPv6 routing.
Transition to IPv6 hosts is based on the assumption that every IPv6 host would have two stacks, IPv6 and IPv4. Such a dual host would also have an API that would support IPv4 and IPv6. The API is likely to be an extension of the current (IPv4) API.
Implementing IPv6 stack on hosts and developing IPv6 capable APIs are essential IPv6 transition steps.
However, these steps are by no means sufficient to make IPv6 useful. In fact, until a sufficient number of networking applications is ported to the IPv6-capable APIs, it would be unrealistic to assume widespread use of IPv6.
Therefore, from a host vendor perspective, the impact of supporting IPv6 is likely to spread across the whole TCP/IP stack from the network layer all the way up to the application layer. The amount of effort needed to accomplish this, and the potentials for introducing software bugs as a result of doing the modifications, should not be underestimated.
Transition to IPv6 routing assumes deployment of routers that would be able to support both IPv4 and IPv6 routing protocols and packet forwarding. The routing protocols that are expected to be used with IPv6 (at least initially) are mostly straightforward extensions of the existing IPv4 routing protocols. Thus we should not expect any significant problems within the IPv6 routing system.
To minimize interdependencies, transition to IPv6 routing assumes that there will be noncontiguous IPv6 segments throughout the Internet. IPv6 connectivity among hosts in different segments will be supported by tunneling IPv6 within IPv4 packets. Therefore, the use of IPv4 tunnels to carry IPv6 traffic over IPv4 only routers is an essential component of the IPv6 routing transition.
IPv6 transition allows for two types of tunnels: automatic and manually configured. Automatic tunnels do not require manually configured individual tunnels. However, the use of automatic has two requirements. IPv6 addresses of the hosts that are reachable through automatic tunnels have to be IPv4 compatible, and also IPv4 addresses that are used to form IPv6 addresses of these hosts (IPv4 compatible addresses) have to be routable. In addition, the use of automatic tunnels is currently defined only when the remote endpoint of a tunnel is a host. Use of automatic tunnels between routers is not defined.
The ability to form automatic tunnels between any pair of IPv6 hosts whose IPv6 addresses are IPv4 compatible allows these hosts to use IPv6 encapsulated into IPv4 end-to-end, without requiring any routers on the path between these hosts to support IPv6. This facilitates the transition of Ipv6 host addresses to be undertaken independently of the upgrade to Ipv6 routing.
IPv6 Security.     Security is a built-in (feature) of the Ipv6 protocol. Security takes the form of both authentication and encryption at the IP level in the new protocol. Ipv6 does not, however, have procedures for authorization; that is still in the domain of application-level programs.
The IETF has an organization known as the IP Security (IPsec) Working Group, which is responsible for developing standards for IP-layer security mechanisms for both IPv4 and IPv6. The group is also developing generic key management protocols for use in the Internet.
Authentication provides the ability for a recipient of a packet to be sure that the source address is authentic, and that the packet has not been altered during transmission. Encryption ensures that only the intended recipient can read the content of the packet.
To successfully deliver these benefits, a key system is employed, whereby senders and receivers agree on the key value to be used. The generic key management system adopted by the designers of Ipv6 is the ISAKMP-OAKLEY mechanism. ISAKMP stands for the Internet Security Association and Key Management Protocol, it provides a generic implementation of key management protocols. ISAKMP messages are exchanged over UDP using port 500. ISAKMP allows several types of key exchange mechanisms to be used, but in the case of Ipv6, the OAKLEY proposals seem most likely to be adopted.
In addition to the key system, senders and receivers must generate a set of agreements that constitute a security association. This association consists of the key, the authentication or encryption algorithm and other parameters, such as the lifetime of the key. With a security association in place, receivers will only decode a packet if the packet can be linked with a particular security association. To this end, all Ipv6 authenticated and encrypted packets carry a Security Parameter Index (SPI). Typically the SPI is chosen by the receiver, to specify the way a packet must be constructed to be properly received.
In practical terms, authentication is delivered in the IPv6 world via one of the generic header extensions previously discussed, the Authentication Header. The authentication data is generated by performing a mathematical operation on the source address, plus some fields of the IP header, then sending this value along with the original packet contents. The algorithm used to generate the encrypted value (referred to as the checksum) is keyed MD5, which is a variant of the Message Digest 5 algorithm.
This algorithm is extremely difficult to reverse engineer and ensures that the source address has not been tampered with and the packet originates from the expected source.
The Authentication Header does not however encrypt the payload. At this stage packets are still vulnerable to being read by those not intended as the recipient. When this is to be avoided, the Encrypted Security Payload (ESP) header is used. The ESP is always the first header after the IPv6 header, as it encrypts the authentication and payload data. The default method of encryption is based on a Data Encryption Standard, known as Cipher Block Chaining.
The enhanced security functions provided at the IP layer of Ipv6, will lend themselves to use with mobile computers, communication between secure hosts, and to securely perform network operations such as neighbor discovery and the exchange of route information. However, it must be noted that if options such as being able to encrypt route updates, a significant increase in route processor load will be experienced, particularly during times of link failure, that cause triggered updates and route re-calculation to be performed.
Ipv6 over Different Link Level Topologies.     Although the previously discussed Neighbor Discovery procedures are equally applicable across different media, there are some differences to the way that Ipv6 packets are constructed for specific link level topologies.
Ethernet is the simplest case, so let's look at that first. An Ethernet packet carrying IPv6 data will look like the packet in Fig. 4-32. As previously discussed, Ethernet II headers have a type field that identifies the network layer protocol occupying the data field in the Ethernet packet. Ipv6 uses a type field value of 86DD.
Figure 4-32: An Ethernet packet encapsulating IPv6.
In an Ethernet environment, each workstation's IPv6 address is derived by combining the Link Local Prefix (which is assigned by a local address server) and the 64-bit EUI address of the interface. This address is then used as the source Ipv6 address in the Ipv6 header. Link level addresses of devices on the same network segment will be determined by the generic Neighbor Discovery routines.
Ipv6 in a FDDI environment is very similar, with only a few differences. FDDI is a token environment with counter-rotating tokens circulating through the physical ring that connects the FDDI nodes. Each frame contains a FDDI and LLC header, which precedes the Ipv6 header, as shown in Fig. 4-33.
Figure 4-33: An FDDI packet encapsulating IPV6.
FDDI Ipv6 addresses are generated in exactly the same way as Ethernet Ipv6 addresses, by combining the Link Local Prefix and the link level 64 bit EUI format address of the FDDI interface. The rest of the packet fields can be described as follows:
FC is the FDDI frame code, which is set to a value in the range 50 to 57 and can be used to define the frame's priority in the ring.
The Destination and Source FDDI addresses will be 48 bit values assigned to the interface.
The Destination and Source Service Access Point (DSAP and SSAP) are set to 33 hex, and the Link Level Control CTL field is set to 03 to denote unnumbered information.
The Organizationally Unique Identifier (OUI) will be set to zero and the Ethertype will be set to 86DD, to identify Ipv6 as the network layer protocol.
A token ring frame is constructed as shown in Fig. 4-34, and essentially uses the same fields as a FDDI packet, plus the extra fields necessary for token ring operation. As with Ipv4 within a token ring frame, the token ring frame encapsulation uses the SNAP (Sub-Network Access Protocol) encapsulation type.
Figure 4-34: A token ring packet encapsulating IPV6.
The DSAP, SSAP, CTL and OUI fields are as for an FDDI packet, with the Start Delimiter, Access Control, Frame Control, Frame Check Sequence and Frame Status as per the token ring standards. Token ring interfaces use 48 bit MAC addresses, which are used to build EUI addresses for use in constructing the Ipv6 address in the normal manner. Token ring environments can be extended by the use of a Routing Information Field, to make use of source routing. In these environments, the RIF is inserted directly after the source MAC address.
The Point to Point Protocol (PPP) will be used for transferring Ipv6 packets over serial links. PPP is a link level protocol that, like Ethernet, supports several network layer protocols. A PPP session starts with a link level negotiation that must complete before the network layer can establish communication. To open Ipv6 communication, the Ipv6 Control Protocol (Ipv6CP) also needs to complete a negotiation process. Ipv6CP is similar to the regular PPP Link Control Protocol, and in this case is used by end stations to negotiate Ipv6 options like compression algorithms to be used. Ipv6CP uses hex value 8057 in the PPP protocol type field. Once Ipv6CP has completed negotiation, Ipv6 packets use a protocol field value of hex 0057.
The interesting part with Ipv6 over PPP comes when it's time to assign an Ipv6 address to an interface. With the previous link level protocols, there was a globally unique EUI address to work with, to ensure that the Ipv6 address generated for the interface was globally unique. Typically serial interfaces do not have such an address assigned. To overcome this situation, PPP interfaces use a 64 bit "interface token" that ensures interface on either end of the PPP link have unique addresses. The 64 bit token is concatenated with the prefix FE80::/64 to produce a link-local address for use on the PPP link. There are four options to choose from, when constructing the IPv6 interface token.
  Use an EUI that is owned by the device using the serial port. This works well for devices like routers that use a LAN interface to connect a LAN to a WAN, as the LAN interface will have a MAC and hence EUI address assigned. This does not however work so well for stand–alone PCs that do not have a LAN connection, no such MAC address is assigned in that situation.
  If no EUI is available, build a unique 64 bit address from some unique value associated with the device, such as a telephone number.
  If neither EUI nor unique values are available, choose a random value from a number generator.
  If no number generator is available, set the source Ipv6 address to zero.
Once each interface has decided upon its token value, the interface on each end of the PPP link will confirm that the other is using a different token value and communication begins.

 


 
Books24x7.com, Inc © 2000 –  Feedback